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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Project Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within EP SCP and may change following formal 
EP SCP approval. If EP SCP modifies the contents of the present document, it will then be republished by ETSI with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x: the first digit: 

early working draft; 

1 presented to EP SCP for information; 

2 presented to EP SCP for approval; 

3 or greater indicates EP SCP approved document under change control. 

y: the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z: the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage one description of the Transport Protocol, CAT_TP, for CAT apphcations 
based on TS 102 223 [1]. 

The Bearer Independent Protocol as defined in TS 102 223 [1] allows a CAT application on the UICC to estabUsh a 
data channel with the terminal, and through the terminal either to a remote server in the network or to a remote device in 
the Personal Area Network (PAN). The Bearer Independent Protocol obviously inherits the properties of the bearer and 
the network protocols it uses and may stand on top of unreliable transport protocols (such as UDP). 

The present document contains the core requirements for the CAT_TP between the card and a remote entity to ensure 
acknowledgement, segmentation/fragmentation, retransmission of messages, etc. The transport mechanisms specified 
are independent of applications and used bearers. Even if the current definition of the CAT_TP protocol is focused on 
the Bearer Independent Protocol, it does not prevent the CAT_TP to be used over future UICC-TE communication 
protocol. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI TS 102 223: "Smart cai'ds; Card Application Toolkit (CAT)". 

[2] ETSI TS 102 225: "Smart cards; Secured packet structure for UICC based applications". 

[3] ETSI TS 102 226: "Smart cards; Remote APDU structure for UICC based applications". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

bearer independent protocol: mechanism by which the terminal provides the UICC with access to the data bearers 
supported by the terminal and the network 

NOTE: As defined in TS 1 02 223 [ 1 ] . 

CAT_TP client: entity which initiates a CAT_TP link to the CAT_TP server, and applies during the connection phase 
only 

NOTE: It could be on the UICC or on the remote entity. 

CAT_TP server: entity which receives a CAT_TP link establishment request from a CAT_TP client, and applies 
during the connection phase only 

NOTE: It could be on the UICC or on the remote entity. 
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CAT_TP entity: entity able to open a CAT_TP link, exchange CAT_TP PDUs (see annex B) and close a CAT_TP link 

CAT_TP Service Data Unit: in the reference model for OSI, amount of information whose identity is preserved when 
transferred between peer (N + l)-layer entities and which is not interpreted by the supporting (N)-layer entities 

NOTE: Here (N)-layer is the CAT_TP layer. 

Physical link: is composed of the Bearer Independent Protocol channel between the UICC and the TE and a bearer 
specific link between the TE and the remote entity 

CAT_TP link: logical link between CAT_TP entities over which CAT_TP PDUs are exchanged 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

BIP Bearer Independent Protocol 

CAT Card Application Toolkit 

CAT_TP Card Application Toolkit Transport Protocol 

ETSI European Telecommunications Standards Institute 

FES For Further Study 

PAN Personal Area Network 

PC Personal Computer 

PDA Personal Digital Assistant 

PDU Protocol Data Unit 

SDU Service Data Unit (in the context of the present document, a CAT_TP SDU) 

TE Terminal Equipment 

UICC Universal Integrated Circuit Card 

WAN Wide Area Network 



Description 



The Bearer Independent Protocol, as defined in TS 102 223 [1], provides to the UICC a standardized way to use TE 
bearers to communicate with remote entities in a WAN or in a PAN. The UICC and the TE exchange data together. The 
TE and the server exchange data together. According to figure 1, the physical link is composed of the BIP and the 
Bearer Specific Protocol between the TE and the remote entity. Several CAT_TP links can share a physical link. 
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Figure 1 : Data exchanges overview 

Without the CAT_TP, the CAT application is unable to know if the remote entity has received the data sent. Moreover, 
without CAT_TP, the remote entity possibly receives data without transport information such as the emitter identity, 
packet numbering or transmission status, etc. 

The CAT_TP aims to provide the possibly missing transport functionalities. 
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5 Requirements 

5.1 Transport requirements 

5.1.1 General requirements 

The CAT_TP shall allow enhancement without compromising backward compatibility. 

The CAT_TP flexibility shall be considered for the best efficiency for applications and bearers, (e.g. to gain 
bandwidth, performances, by activating/deactivating some of the CAT_TP features). 

Deployed protocols shall be considered as a possible stage 2 solution. 

A negotiation mechanism, between CAT_TP entities, shall be available for all CAT_TP negotiable features 
(e.g. receive/transmit buffers, acknowledgement mechanisms...) in order to achieve CAT_TP interoperability. 

Sets of valid combinations of CAT_TP negotiable features shall be defined. There shall be a limited number of 

sets. 

The CAT_TP shall provide full-duplex communication. 

5.1 .2 Physical link requirements 

This clause is left FFS. 

5.1 .3 CAT_TP link requirements 

The CAT_TP shall allow a connection oriented mode. A CAT_TP connectionless mode need is FFS. 

5.1 .4 CAT_TP connection mechanisms requirements 

5.1.4.1 Definition 

The CAT_TP connection oriented mode provides functions to open and to close CAT_TP links. The connection set-up 
is the request from CAT_TP client to CAT_TP server to establish a CAT_TP link with CAT_TP specific parameters, 
and optional parameters for physical link establishment. This mechanism includes the closing of CAT_TP link. The 
connection set up could be achieved by the UICC or by the remote entity. 

5.1.4.2 Functional requirements 

The connection set-up shall be done with specific PDUs. 

After the issuance of the link establishment request, the CAT_TP client shall wait for a link establishment 
response in a finite time. 

Upon the connection set-up, an error handling mechanism shall be available on the CAT_TP client side. 

Several connection set-ups shall be able to be performed on the same physical link. This ends up with several 
CAT_TP links established at the same time on the same physical link. 

During the CAT_TP connection set up, it shall be possible to choose between using already open physical 
links or opening a new one depending of the optionally given physical link parameters. 

The CAT_TP client shall negotiate with the CAT_TP server the maximum PDU size and the maximum SDU 

size. 

At any moment, the CAT_TP client or CAT_TP server shall be able to close a CAT_TP connection. 
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5.1 .5 Segmentation mechanism requirements 

5.1.5.1 Definition 

This mechanism is the spht of a SDU into several PDUs. 

5.1.5.2 Purpose 

In case a SDU is larger than the maximum PDUs size negotiated during the connection step (emission and reception), a 
segmentation and re-assembly mechanisms shall be used. 

5.1.5.3 Functional requirements 

• Both CAT_TP entities shall support this segmentation and re-assembly requirements. 

• There shall be an available mechanism to handle several out of sequence PDUs belonging to one SDU. 

• There shall be an available mechanism to handle several PDUs from different SDUs. 

5.1 .6 Reliable message exchange requirements 

5.1.6.1 Definition 

Acknowledgement and retransmission allow reliable message exchange. The acknowledgement allows the CAT_TP 
receiving entity to indicate to the CAT_TP sending entity it has received the previous data with or without errors. In 
case of bad transmission, retransmission applies. 

5.1.6.2 Purpose 

This mechanism allows CAT_TP entities to exchange data in a reliable manner. 

5.1.6.3 Functional requirements 

• The acknowledgement and the retransmission shall be possible, if requested by CAT_TP entities: 

at the SDU level; 
at the PDU level; 
for several PDUs. 



• 



A mechanism shall be available to handle lost or corrupted (i.e. corrupted header) PDUs and SDUs (data or 
control messages). 



• Checksum mechanism is not considered to be necessary since data integrity is considered to be handled by 
physical link. 

• Flow control shall be considered in the CAT_TP. 

5.2 Application requirements 

5.2.1 Upper layer identification mechanism requirements 

5.2.1.1 Purpose 

This feature is needed to inform the receiving entity of the data format. 
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5.2.1.2 Functional requirements 

There shall be a mechanism to identify an upper layer, if any. For example, it shall be able to identify the security layer 
as defined in TS 102 225 [2]. 

5.2.2 CAT_TP entities identification mechanism requirements 

5.2.2.1 Purpose 

This feature allows CAT_TP entities to uniquely identify each other. 

5.2.2.2 Functional requirements 

• There shall be a mechanism to uniquely identify a CAT_TP link established between two CAT_TP entities. 

• There shall be a mechanism to uniquely identify the sending CAT-TP entity. 
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Annex A (informative): 
Working environment 
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Figure A.1 : Working environment description 

Actors of the working environment: 

• UICC: Universal Integrated Circuit Card. 

• TE: Terminal Equipment. 

• OTA Server: Over The Air Server; manage and administrate the UICC. 

• Gateway: Bridge to "service provider" content servers. 

• Content server: Server providing user oriented services; e.g. Bank, loyalties, etc. 

• PDA: End user portable device. 

• PC: End user computer. 
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Annex B (informative): 
PDU, SDU description 

Regarding the OSI model, PDUs and SDUs shall be interpreted as follow. 
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Figure B.I : Layers relation 

Within the scope of the present document, the definitions of PDUs and SDUs assume that CAT_TP is considered as the 
reference layer. 
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Figure B.2: Responsibility between application and CATTP 

Application is responsible for data and its associated SDUs, if any. The CAT_TP is responsible to transfer those SDUs 
in a reliable manner to its peer entity and to split them into several PDUs, if necessary. 
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Annex C (informative): 
Change history 
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